The present invention relates to managing Internet Protocol version 6 (IPv6) data packets in an item of communications equipment.
Some of such data packets comply with the Network Discovery Protocol (NDP) as defined by Internet Engineering Task Force (IETF) Request for Comments (RFC) 2461.
That protocol defines “self-configuration” and “Network Discovery” (“ND”) packets that make it possible for an item of equipment of an IPv6 communications network to determine its address and to be aware of the various items of equipment connected over each of the links. That protocol also enables each item of equipment to be informed of the changes arising on said links, e.g. when a “neighbor” item of equipment becomes inaccessible. The item of equipment can be a router (or node), a host (i.e. a terminal), a gateway, or any other device possessing means for transmitting and receiving IPv6 data packets.
In addition, by means of that protocol, the operator of the communications network no longer has to configure each of the items of equipment of its network manually, because said network self-configures by exchanging self-configuration packets that comply with the NDP.
However, it is necessary to make the data packets secure, in particular so that an unauthorized host cannot connect to the communications network. Using the NDP, it is possible for a host to usurp the identity of another host by making the access equipment that gives access to the network believe that it has the MAC interface for the network.
Such a need is crucial in radio-communications networks in which the hosts are mobile and are thus not physically and statically connected to access equipment.
It is thus important to provide the NDP with security mechanisms. RFC 3756, entitled “IPv6 Neighbor Discovery (ND) Trust Models and Threats” and dated May 2004, poses the problems and requirements for making the NDP secure. That RFC emphasizes that the prior work was based on the “IPsec” security protocol, but that that protocol requires encryption keys to be determined manually. Since that manual step is incompatible with the automatic nature of the NDP, some other approach is necessary.
That approach is proposed by IETF RFC 3971 entitled “Secure Neighbor Discovery (SEND)” and dated March 2005. From a technical point of view, the SEND mechanism consists in adding fields containing security information to each of the messages of the NDP, and more precisely to the ends of those messages. Those fields are defined partially by the RFC as the following fields: “RSA Signature option”, “CGA option”, “Timestamp option”, and “Nonce option”. However, the specifications of RFC 3971 leave open the possibility of subsequently adding new “option” fields in order to enrich the NDP and the SEND mechanism further.
Currently, the first implementations of the SEND mechanism are only just starting to be defined. Some of those implementations are based on an operating system of the Unix type. That system can be a Linux or a BSD operating system, for example. Conventionally, the core of an operating system dedicated to communications equipment includes one or more protocol stacks that manage data packet transmission in a manner that is transparent for the applications. Such IPv6 protocol stacks thus implement the software mechanisms necessary for managing the NDP and the SEND mechanism.
However, such an approach suffers from major drawbacks. The SEND mechanism might be upgraded, in particular by new “option” fields being added. Each upgrade thus requires the core of the operating system to be modified. Unfortunately, modifying an operating core (or a core of an operating system) is a complex and therefore costly operation.